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Declaration of Sung I. Oh 

Sir: 

I, Sung I. Oh, declare: 

1. I am an associate at the law firm of Squire, Sanders & Dempsey L.L.P. and 
licensed to practice in California and before the U.S. Patent and Trademark Office. 

2. On August 19, 2003, 1 called Nathan Leach at the phone number (713) 623-0929, 
and the business telephone message indicated that the business was Paymetric, Inc. The voice 
message requested a four digit extension number to direct the call, at which time I dialed the 
4230 extension. Thereafter, a male voice identified himself as "Nathan." I asked whether this 
was Nathan Leach, and Mr. Leach confirmed his identity to me. 

3. I identified myself as Sung Oh, a patent attorney with the law firm of Squire 
Sanders. I indicated that I represent Nodus Technologies. I further explained that Squire 
Sanders has prepared and filed a U.S. patent application for Nodus Technologies, Inc. in which 
Nathan Leach is named as a co-inventor. 

4. Mr. Leach then inquired about the reason for the call. I explained to Mr. Leach 
that as a former employee of Mekorma, the company at which the invention was conceived, Mr. 
Leach needed to review the U.S. application to confirm that he was properly named as a 
coinventor. I further explained that as a co-inventor of the invention, we needed his signatures 
for certain paperwork such as a Declaration and an Assignment. 




by certify that on , which is the date I am 



ping 



this certificate, I am depositing this correspondence and all 
identified attachments with the U.S. Postal Service, first class mail, 
postage prepaid, in an envelope addressed to the Commissioner for 
Patents, P.O. Bo^l450, Alexandria, Virginia 22313-1450. 




Kiersten Mishalany 
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5. Mr. Leach acknowledged that he had worked at Mekorma with Donte Kim, 
another software engineer at Mekorma and a co-inventor of the application, to develop an 
integration software program. He was adamant in stating that he did not want anything to do 
with the U.S. patent application directed to the integration software program. He stated that he 
would not sign any paperwork related to the patent application. Mr. Leach then abruptly 
terminated the call by hanging up the telephone. 

6. On August 26, 2003, I mailed a letter to Mr. Leach via Certified Mail to the 
address of 17407 Old Court Drive, Tomball, TX 77377, in an envelope bearing this firm's logo 
"Squire, Sanders & Dempsey L.L.P.," along with a Return Receipt Requested enclosing a cover 
letter, Declaration and Petition and Assignment for his signature, as well as a copy of the U.S. 
application for his review. A copy of the letter is attached as Exhibit A. 

7. On September 2, 2003, the U.S. Postal Service returned to my law firm the 
unopened package containing the letter and enclosures that had been mailed to Mr. Leach with 
three ink stamped messages indicating "Return to Sender" and the hand written message 
"8/29/03 Refused." A copy of the unopened package is attached to this declaration as Exhibit B. 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. A 





LosAngeles/122417.1 



Squire 



LEGAL 



,<: 



Squire, Sanders & JDempsey L.L.P. 

801 South Figueroa, 14th Floor 
Los Angeles, California 90017-5554 




COUNSEL 
WORLDWIDE 



Office: +1.213.624.2500 
Fax: +1.213.630.4444 




Direct: +1.213.689.5176 
soh@ssd.com 



August 26, 2003 



BY CERTIFIED MAIL 

RETURN RECEIPT REQUESTED 



DECLARATION AND 
ASSIGNMENT FOR U.S. PATENT 
APPLICATION SERIAL NO. 
10/624,412. 



□ DO NOT WISH TO SIGN 



Mr. Nathan Leach 
17407 Old Court Drive 
Tomball, TX 77377 

Re: For: SYSTEM FOR INTERFACING SOFTWARE PROGRAMS 
U.S. Patent Application Serial No. 10/624,412 
Client\Matter No.: 58255-00005 



Dear Mr. Leach: 

As discussed in our telephone conversation on August 19, 2003, 1 am with the law firm of Squire, 
Sanders & Dempsey L.L.P., which has filed the above U.S. Patent Application (the "Application") on 
behalf of our client Nodus Technologies, Inc ("Nodus"). The Application was filed listing you and Donte 
Kim as the two co-inventors, which is directed to an idea(s) that was developed while you and Donte Kim 
were working at Mekorma. By virtue of certain agreement between Mekorma and Nodus, the rights under 
the Application is owned by Nodus. 

The Application was filed without a signed declaration, so we anticipate receiving what is called a 
"Notice to File Missing Parts" from the U.S. Patent and Trademark Office. This is a request from the 
Patent Office to submit the signed declaration from the inventor(s) of the Application. The reason for the 
• August 19 telephone call was to request your cooperation in signing certain documents related to the 
Application such as a declaration and an assignment. 

During our telephone conversation, you indicated that you did not want to sign any paper work 
related to the Application. If this is your current position, then please check the above box next to 
indicate that you "DO NOT WISH TO SIGN DECLARATION AND ASSIGNMENT FOR U.S. Patent 
Application Serial No. 10/624,412," and return this cover letter along with enclosures to me for record 
keeping in the stamped self-addressed envelope provided to you. If my office does not receive any paper 
work from you related to the Application within 30 days from the date of this letter, then we will presume 
that you will not sign any of the paper work related to this Application. On the other hand, if you have 
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decided to sign the paper work, then please review the enclosed copy of the Application and sign the 
accompanying declaration and the assignment, both before a notary. Once signed, please return the 
Declaration and the Assignment to me in the stamped self-addressed envelope. 

If you have any questions about the above subject matter you may contact me, however, it is 
advisable that you seek your own counsel for advise on the above subject matter. Be reminded, however, 
of the confidentiality agreement you signed on June 29, 1999. In addition, under California Labor Code § 
2860: 

Everything which an employee acquires by virtue of his employment, except the 
compensation which is due to him for his employer, belongs to the employer, whether 
acquired lawfully or unlawfully, or during or after the expiration of the term of his 
employment. 

As such, the idea(s) you have developed that were within the scope of your employment with 
Mekorma, belong to Mekorma, and by virtue of the agreement between Nodus and Mekorma, the idea(s) 
that are embodied in the Application belong to Nodus. 

With regard to patent office procedures, if the inventor or anyone else substantively involved in 
the prosecution of this application are aware of information which might be deemed material to the 
patentability of the application, such information should be promptly brought to our attention. 

Prior art including patents and other publications which the Examiner might consider to be 
important would likely be considered material information. Examples of other information previously 
considered to be material include the existence of other U.S. applications of the applicant or assignee 
directed to closely related or overlapping subject matter. Further, prior art disclosed or cited in such other 
U.S. applications and corresponding foreign applications has also been considered to be material. If you 
have any of such information, please forward me a copy. 




SQUIRE, SANDERS & DEMPSEY L.L.P. 



SlO/rlf 



Enclosures: ( 1 ) a copy of the patent application 

(2) corresponding Declaration and Assignment 



cc: 



Donte Kim (w/o enclosures). 
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DECLARATION and PETITION 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name. 

I believe I am the original, first and sole inventor (if only one name is listed below) or an 
original, first and joint inventor (if plural names are listed below) of the subject matter which is 
claimed and for which a patent is sought on the invention entitled "System for Interfacing 
Software Programs." 

[ X ] is attached hereto 

I hereby state that I have reviewed and understand the contents of the above identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the examination of 
this application in accordance with Title 37, Code of Federal Regulations, § 1 .56(a). 

I hereby claim foreign priority benefits under Title 35, United States Code, § 1 19 of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified 
below any foreign application for patent or inventor's certificate having a filing date before that 
of the application of which priority is claimed. 

Prior Foreign Application(s) 

Priority Claimed 

NONE NONE NONE □ Yes □ No 

(Number) (Country) (Day, month, year) 

I hereby claim the benefit under Title 35, United States Code, § 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States application in the manner provided by the 
first paragraph of Title 35, United States Code, § 112, I acknowledge the duty to disclose • 
material information as defined in Title 37, Code of Federal Regulations, § 1 '.56(a) which 
occurred between the filing date of the prior application and the national or PCT international 
filing date of this application: 

60/397,737 07/22/2002 ' Pending ' 

(Application Serial No.) Filing Date (Status) (Patented, pending, abandoned) 

60/455,008 03/14/2003 Pending 

(Application Serial No.) Filing Date (Status) (Patented, pending, abandoned) 

I hereby declare that all statements made herein of my own knowledge are true and that 
all statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made are 
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punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. 

Wherefore I pray that Letters Patent be granted to me for the invention or discovery 
described and claimed in the foregoing specification and claims, and I hereby subscribe my name 
to the foregoing specification and claims, declaration, power of attorney, and this petition. 

Full name of sole or first inventor Donte Kim 

Inventor's signature 

Date 

Residence Alta Loma, California 

Citizenship United States 

Post Office Address . 6771 Amberwood Drive, Alta Loma, California 91701 



Full name of second inventor Nathan Leach 

Inventor's signature 

Date 

Residence Tomball, Texas • 

Citizenship United States ' 

Post Office Address 17407 Old Court Drive, Tomball, Texas 77377 
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ASSIGNMENT 

WHEREAS, I, Nathan Leach, one of the co-inventors and the ASSIGNOR herein, have 
invented a SYSTEM FOR INTERFACING SOFTWARE PROGRAMS, for which on July 21, 
2003, Application Serial No. 10/624,412 for Letters Patent of the United States was filed, which 
application has been executed by me concurrently herewith and of which inventions and 
improvements I am the joint owner; and 

WHEREAS, Mekorma (ASSIGNEE) is a corporation organized and existing under the 
laws of California, having a place of business at 3000 S. Robertson Boulevard, Suite 290, Los 
Angeles, California 90034. ASSIGNEE desires to acquire the entire right, title and interest in 
and to the inventions, applications and letters patent to be granted and issued for the inventions 
and applications; 

NOW, THEREFORE, for and in consideration of the sum of One Dollar ($1.00) by the 
ASSIGNEE to myself is paid, and other valuable consideration, the receipt and legal sufficiency 
of all of which is hereby acknowledged, I, the said ASSIGNOR, have sold and do hereby sell, 
assign, transfer and set over unto said ASSIGNEE, its successors and assigns, the entire right, 
title and interest in and to said inventions and all improvements thereon, in and to said 
application for Letters Patent thereon, in and to applications pertaining to or based upon said 
inventions and applications, including divisional and continuing applications and continuations- 
in-part, and in and to any and all Letters Patent which may be granted and issued on said 
inventions and applications, or any of them, not only for, to and in the United States of America, 
its territories and possessions, but for, to and in all countries foreign thereto, together with and 
including all priority rights based upon any and all applications in the United States of America 
covered by this Assignment. 

And for the above-named considerations, I do hereby agree that I will, at the request of 
said ASSIGNEE, execute any and all applications for Letters Patent for said inventions and any 
and all other papers and documents and do all other and further lawful acts that said ASSIGNEE 
may deem necessary or desirable to obtain Letters Patent on said inventions, to secure the grant 
of such Letters Patent and to perfect and vest in the ASSIGNEE the entire right, title and interest 
in the inventions, applications and Letters Patent. 

And for the above-named considerations, I do hereby authorize and empower the 
ASSIGNEE, its successors and assigns, to apply for and obtain, in its or their own names, Letters 
Patent for the said inventions before competent International Authorities and in any and all 
countries foreign to the United States in which applications for Letters Patent can be so made or 
Letters Patent so obtained. 

Dated: 

Nathan Leach 
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STATE OF TEXAS ) 

) ss. 

COUNTY OF J 

On this day of , 2003, before me 5 

the undersigned Notary Public, personally appeared Nathan Leach, personally known to me (or 
proved to me on the basis of satisfactory evidence) to be the person whose name is subscribed to 
the within instrument and acknowledged to me that he/she executed the same in his authorized 
capacity, and that by his signature on the instrument, the person or the entity upon behalf of 
which the person acted, executed the instrument. 

WITNESS my hand and official seal. 

(SEAL) Notary.Public 



Dated: 

Nathan Leach 



LosAngeles/l 22423.1 
8/19/03 
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System for Interfacing Software Programs 

Background of the Invention 
[0001] 1. Related Applications. 

[0002] This application claims priority to two U.S. provisional applications: (1) U.S. 
Provisional Application No. 60/397,737, filed July 22, 2002, entitled System for Processing 
Electronic Payment Transactions In Multiple Data Formats; and (2) U.S. Provisional Application 
No. 60/455,008, filed March 14, 2003, entitled System for Interfacing Software Programs, which 
are both incorporated by reference. 
[0003] 2. Field of the Invention. 

[0004] This invention provides a system capable of interfacing software programs with 
different data format requirements. In particular, the system is capable, of interfacing electronic 
payment transactions between an application program and a number of payment processors 
having different data formatting requirements to process the transaction. 
[0005] 3. Background. 

[0006] When a customer uses a credit card to make purchases with a merchant, a number of 
steps need to take place before a transaction can be completed. To begin, the merchant obtains 
the credit card information from the customer to process the transaction. Based on the credit 
card information, the merchant requests an authorization from a payment processor for the 
transaction. The authorization is a process of validating the status of the credit card and 
reserving sufficient funds to cover the amount in the transaction. The payment processor is a 
third-party organization that provides an authorization code for each of the transactions and 
settles the transaction once the merchant provides the service or the goods to the customer. 
[0007] The merchant has many payment processors from which to choose from to process 
the credit card transactions. For example, Verisign®, Paymentech®, Tranvia®, and Nova® are 
a few of the companies that offer payment processing services. Each of these companies offers 
different fee arrangements to entice the merchant to conduct the transactions through its payment 
processor. Besides the different fee structures, different payment processors have different 
requirements in the way that data needs to be formatted in order to process the transaction. Each 
payment processor may require that information be fielded differently, requiring certain 
information in certain order. For instance, a first payment gateway may require, fields in the 

1 
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following order: the first field being the type of credit card being used, i.e., VISA, MASTER 
CARD, or DISCOVER CARD; the second field being the credit card number; the third field 
being the cardholder's name; and the fourth field being the expiration date; in order to process 
the transaction. A second payment processor, however, may require the first field to be the 
cardholder's name; the second field to be the type of credit card; the third field to be the 
expiration date; and the fourth field to be the credit card number; and also ask for a CCV number 
for security. This means that the merchant's system that processes the credit card transaction 
needs to be revised or tailored so that the data is formatted and transmitted correctly to meet the 
data formatting requirements for that particular payment processor to process the transaction. 
For merchants, having different data formatting requirements is a drawback because should the 
merchant decide to later switch to a different payment processor, the merchant's accounting 
software system may need to be reprogrammed to interface with the new data formatting 
requirements. This can take both time and money to implement. 

[0008] To interface the merchant's accounting package system with a payment processor, the 
merchant usually has two options. The first option is to have a customized payment system 
developed specifically for the merchant to allow direct credit card transaction with the payment 
processor or bank. The merchant usually runs the customized payment system on its own server 
developed by a specialized vendor. Developing customized software for a payment system can 
be expensive and time consuming. With the changes in technology, updating and maintaining 
the payment system can be expensive and time consuming as well. 

[0009] The second option for the merchant is to use the services of a third-party gateway. 
The third-party gateway processes payments by providing an interface between. the merchant's 
accounting system and the payment processor, effectively acting as a hub, forwarding 
information to a specific payment processor. With the second option, there are, however, two 
fees for every transaction: one fee to the payment processor and the second fee to the third-party 
gateway. Even with the third-party gateway, the merchant may still need technical staff to . 
integrate the third-party gateway program with the merchant's accounting package. In most 
instances, the third-party gateway will provide the merchant with a software development kit 
(SDK) that allows the merchant's accounting package to interface with the third-party gateway 
software and the payment processor. Implementing the SDK, however, can take up to six weeks. . 
As such, most merchants are reluctant to switch to another payment processor even if better fee 
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arrangements are offered. Thus, there is still a need for an electronic payment system that can 
process electronic payment transactions in multiple formats and communicate with many 
different payment gateways, whether they are gateways, processors, or banks. 

Invention Summary 

[0010] The invention provides an electronic payment system that consolidates data formats, 
input fields, and transmission requirements for interacting with different payment systems such 
as gateways, processors, and banks. The electronic payment system may support many different 
types of payment gateways each with its own data formatting, transmission, and input field 
requirements and provides payment connectivity over electronic networks between buyers, 
sellers, and financial networks. 

[0011] The electronic payment system may also provide an application programming 
interface (API) that allows application software developers and users to connect to different 
payment gateways. The application software may be an e-commerce website, an accounting 
program, an e-commerce website development tool, a point of sale system, and/or any other 
electronic system known to one in the art to process electronic payment transactions. The API 
may allow a user or a developer a choice between multiple gateways, processors, and/or banks, 
so that when a payment gateway is selected,. the appropriate input fields distinguishable between 
required and optional input fields, data formatting, and transmission requirements are met so that 
the application software can interface with the payment gateway. ■ 

[0012] Many modifications, variations, and combinations of the methods and systems of 
processing electronic payment transactions are possible in light of the embodiments described 
herein. The description above and many other features and attendant advantages of the present 
invention will become apparent from a consideration of the following detailed description when 
considered in conjunction with the accompanying drawings. 

Brief Description of the Figures 
[0013] A detailed description with regard to the embodiments in accordance with the present 
invention will be made with reference to the accompanying drawings. 
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[0014] FIG. 1 illustrates a system diagram including an application programming interface 
(API) capable of interfacing application software with many different types of payment gateways 
by wrapping around a software object for each payment gateway. 

[0015] FIG. 2 illustrates a flowchart for installing an API and connecting to many different 
types of payment gateways. 

[0016] FIG. 3 illustrates a. system diagram where application software interfaces with an 
API. 

[0017] FIG. 4 illustrates an interfacing system including the application programming 
interface capable of processing credit card transactions for merchants using different application 
software or systems to process the transactions. 

Detailed Description 
[0018] This following description should not be taken in a limiting sense but is made merely 
for the purpose of illustrating the general principles of the invention. The section titles and 
overall organization of the present detailed description are for purposes of convenience only and 
are not intended to -limit the present invention. 

[0019] FIG. 1 illustrates an interface system 100 including an application program interface 
(API) 102 capable of interfacing an application system 101 with a plurality of processing 
systems 104. The application system 101 and the plurality of processing systems 104 may be any 
type of software that needs to interface to process the transactions. The plurality of processing 
systems 104 may include a processing system_I, processing system_2, and processing 
system_N, where N denotes the number of processing systems within the plurality of processing 
systems 104. That is, N may be any integer. Each processing system 104 may have different 
requirements in the way that data needs to be formatted in order to process the transaction with 
the application system 101 . For instance, the processing system_l may request the data_l in the 
first field, data_2 in the second field, data_3 in the third field and etc. In contrast, the processing 
system_2 may request the data_2 in the first field, data_3 in the second field, and data_l in the 
third field. 

[0020] Another difference in . data formatting requirements may be that the processing 
system_l and processing system_2 may request different fields. For instance, out of possible 
one hundred fields, the processing system_l may request the following fields: field_l, field_3, 
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field J, field_7,. field _8, field_9, Seidell, field_12, field_13, field_15, field_25, field_26, 
field_40 and etc., to process the transaction with the application system 101. In contrast, the 
processing system_2 may request some common and different fields such as field_l, field_3, 
field_13, field_15, field_25, field_26 and etc. In this example, the same input fields for the 
processing system_l and processing system_2 may share the same value or data. In addition, as 
the plurality of processing systems 104 are updated from time to time, the data formatting 
requirements may change to process the data. This means that the application software 101 may 
not be able to directly interface with the plurality of system 1 04. 

[0021] Besides the different formatting requirements, each processing system may have 
different required fields and optional fields to process the transaction. For instance, the 
processing system J may require field_.l, field J2, field J 5, and field_40 with the other input 
fields being optional to process the transaction. The processing system_2. on the other hand may 
require field J, field_2, and field_15 with all other input fields being optional. That is, the data 
for the required fields are needed to process the transaction, but the optional are not, although it 
may be useful in processing the transaction more efficiently and securely. 
[0022] The API 102 interfaces the application system 101 with the plurality of processing 
systems 104. The API 102 is communicateably coupled to connector_l, connector_2, and 
connectorJN corresponding to the processing systenij, processing system_2, and processing 
systemJN, respectively. Each connector is stored with the data formatting requirements in order 
for the processing system corresponding to the connector to process the data. For instance, 
connectorj may be stored with the formatting requirements that the following input fields are 
requested by the processing systemj: field J, field_3, field_5, field_7, field_8, field_9, 
fieldjl, field J 2, field J 3, field J 5, field_25, field__26, field_40 and etc. In addition, 
connectorj may be stored with information that the following input fields are required: field J, . 
field_2, field_15, and field_40, while all other input fields are optional; Likewise, connector_2 
may be stored with- the formatting requirements for the processing system_2 that the. following 
input fields are requested by the payment system_2: field J, field_3, field J 3, field J 5, field_25, 
field_26 and etc, and that input fields field J, field_2, and field_15 are required. 
[0023] The application system 101 based on a predetermined set of rules may instruct the 
API 102 which connector to use. For example, the predetermined set of rules may be: if value or 
data for input field_15 > 0, then connectorj is used, but if not, then connectorj is used. Based 
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on the connector information from the application system 101, the API 102 accesses the 
corresponding connector and retrieves the formatting requirements stored in that connector 
corresponding to the processing system. For instance, if the application system 101 instructs the 
API 102 to use connector_l, the API retrieves the formatting requirements stored in 
connector_l and forwards the formatting requirements to the application system 101. Based on 
the formatting requirements, a quarry is made through the application system 101 to request from 
the user to input the data or value for the input fields: field_l, field_3, field_5, field_7, field_8, 
field_9, field J 1, field J 2, field J 3, field J 5, field_25, field_26, field_40 and etc. In addition, a 
quarry may distinguish the required field(s) from the optional field(s) to efficiently and securely 
process the transaction. The API then retrieves data or value for the input fields corresponding 
to connector_l and forwards the information to the processing system_l for processing the 
transaction. Accordingly, with the connectors corresponding to the processing systems, the API 
102 may interface one software system with another software system having different data 
formatting requirements. 

[0024] The API 102 may operate within the server hosting the application system 101 or 
operate from a remote server. The API 102 may be any type of interfacing object known to one 
in the art, such as, but not limited to, a .COM object, a .NET program, or any type of software 
library, etc., used to facilitate the interaction of programs with each other. The connectors may 
be software objects with the data formatting requirements for the corresponding processing 
system within the plurality of processing systems 104. 

[0025] Figure 2 illustrates an interfacing system 200 including an API 202 for processing 
transactions related to credit cards. Residing between the application system 201 and the 
plurality of payment gateways 204 is the API 202 that allows a merchant to select which 
payment gateway to use in order to process the transaction with the payment processor 206. 
During the initial setup to link the application system 201 to the API 202, the API 202 provides a 
menu with the list of payment gateways 204 that are supported by the API 202. For each 
payment gateway, a corresponding connector may be stored in the connector memory 208 ,with 
the data formatting requirements for the payment gateway. For example, connector_l, 
connector_2, and connector^N may be stored in the connector memory 208 with the data 
formatting requirements for payment gateway^l, payment gateway_2, and payment gateway_N, 
respectively. The merchant may select more, than one payment gateway to process the 
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transaction through a particular payment gateway based on a predetermined condition. The - 
merchant may also later change the payment gateway to process the credit card transaction by 
selecting another payment gateway that is supported by the API 202. 

[0026] The application system 201 is on the merchant side to accept- the credit card 
information. For instance, the application system 201 may be an e-commerce website, an 
accounting program, a point-of-sale (POS). system, credit card swapper, business-to-business 
(B2B) portals, call centers, enterprise resource planning (ERP), customer relationship 
management (CRM), or any other electronic system known to one in the art for processing 
electronic payment. 

[0027] The API 202 may be coupled to the connector memory 208 to have access to 
connector_l, connector_2, and connector_N corresponding to the payment gateway_l, 
gateway_2, and gateway_N, respectively. Each connector includes data formatting information 
with regard to which input fields are requested. In addition, the connector may distinguish which 
fields are required and optional. For example, Table A below may illustrate the input fields 
information requested from the user to process a credit sales transaction through the payment 
gateway_l . As such, the input fields information in Table A may correspond to connector_l : 

Table A 



Field ID 


Field Name 


Field Decryption 


Required 


Field 1 


AccountNum 


Credit Card Number 


Yes 


Field 3 


~ Exp 


Expiration Date MMYY 


Yes 


Field 5 


AVSname 


Card Holder First Name 


. No 


Field 7 


AVSname 


Card Holder Last Name 


■ No 


Field 8 ' 


AVSaddressl . 


Card Holder Address 1 


No 


Field 9 


AVSaddress2 


Card Holder Address 2 


No 


Field 11 


AVScity 


Card Holder City 


No 


Field 12 


AVSstate 


Card Holder State 


No 


Field 13 


AVSzip.- 


Card Holder Zip 


No 


Field 15 


Amount 


Transaction Amount 


Yes 


Field 25 


Comments 


User Comment 1 


No 


Field 26 


Comments 


User Comment 2 


No 


Field 40 


OrderlD 


Invoice Number 


Yes 


Field 72 


ECOrderNum 


EC Order Number 


No 


Field 73 


TzCode 


Time Zone 


No 


Field 74 


CurrencyCode 


Currency Code 


No 


Field 75 


CurrencyExponent 


Currency Exponent 


No 


Field 76 


TxDateTime 


Transaction Date 


No 


Field 77 


ShippingRef 


Shipping Reference 


No 


Field 78 


CardSecVal 


Card Section Value 


No 
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Field_79 MessageType Message Type No - 

[0028] In connectorj, the following input fields are required: field_l, field_3, field_15, and 
field_40, and all other input fields may be optional. Different payment gateway may request 
different input fields. For example, Table B below illustrates. the different input fields request 
for payment gateway_2. As such, the input fields information in Table B corresponds to 
connector 2: 



Table B 



Field ID 


Field Name 


Field Decryption 


Required 


Field 1 


ACCT 


. Credit Card Number 


Yes 


Field 3 ■ 


EXPDATE 


Expiration Date MMYY 


Yes 


Field 13 


ZIP 


Card Holder Zip 


No 


Field 15 


AMT 


Transaction Amount 


Yes 


Field 25 


COMMENT 1 


User Comment 1 


No 


Field 26 . 


COMMENT2 


User Comment 2 


No - 


Field 34 


PONUM 


PO Number 


No 


Field 35 


DESC 


General Description 


No 


Field 36 


DESC1 


General Description 1 


No 


Field 37 


DESCZ 


General Description 2 


No 


Field 38 


DESC3 


General Description 3 


No 


Field 39 


DESC4 


General Description 4 


No 


Field 40 


INVNUM 


Invoice Number 


No 


Field 41 


SHIPTOZIP 


Ship to Zip 


No 


Field 42 


TAXAMT 


Tax Amount 


No 


Field 55 


COMMENT3 


Account Holder Street 


No 



[0029] Tables A and B illustrate that each payment gateway may request different input 
fields and designate different required fields. In this example, the input field_40 that is required 
for connector_l may not be requested by connector_2. 

[0030] Still further, connectorj may have different formatting requirements from 
cormector_2 in the following ways: The connector_l may require the following input fields with . 
the following data: the first field corresponding to data_l = first name; the second field 
corresponding to data_2 = last name; the third field corresponding to data_3 = the type of credit 
card, such as Visa® or Master Card®; the fourth field corresponding to data_4 = credit card 
number; the fifth field corresponding to detta_5 = CCV number; the sixth field corresponding to 
data_6 = expiration date of the credit card; and the seventh field corresponding to data_7 = zip 
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code of the billing address of the credit card. The payment server 206 may not require . all seven 
input fields to process the transaction. For instance, the payment server 206 may only require the 
first, second, third, fourth, and sixth fields to process the transaction, but the fifth and seventh 
input fields may be further requested as optional fields to improve the efficiency in processing 
the transaction or for security reasons. In contrast, the connector_2 may require the following 
input fields corresponding to the following data: the first. field corresponding to data_3, which is 
a type of credit card used for the transaction; the second field corresponding to data_4; the third 
field corresponding to data_l; the fourth field corresponding to data_2; the fifth field 
corresponding to data_5 = CCV number; and the sixth field corresponding to data_6. The 
payment server 208 may require the first, second, third, fourth, and sixth fields to process the. 
transaction, with the fifth field being optional. 

[0031] The API 202 may provide a menu list to the application software 201 to allow a user 
to select the payment gateway to process the credit card transactions. When the selection is 
made, the connector corresponding to the gateway is set. When the merchant requests a credit 
card transaction, the application system 201 based on the merchant's payment gateway selection, 
communicates to the API 202 which connector to use. For example, if the merchant is using 
payment gateway_2, the application system 201 communicates to the API 202 that connector_2 
is to be used for the credit card transaction. The API then communicates with the connector 
memory 208 to retrieve connector_2, and the data formatting information in connector_2 is 
forwarded to the application system 201. Based on the information contained in connection_2 s 
the application system 201 quarries the merchant or the credit card user for the input fields for 
both the required and optional fields. In addition, the quarry may distinguish between the 
required and optional fields so that the data or value may be gathered efficiently and securely. 
[0032] Each connector may be in the form of a software object that is used by the application 
system 201 to quarry the merchant or the credit card user. The software objects corresponding to 
the payment gateways may include software to format the inputted fields by the merchant and 
transmit the information to the corresponding payment gateways. That is, the software object 
may act as a messaging agent between the application system 201 and the corresponding 
payment gateway. Once the merchant inputs the required input fields, along with the optional 
input fields, if any, the application system 201 forwards the input fields contained in the software 
object to the API 202. The API then transmits the software object to the corresponding payment 
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gateway for processing the transaction. The gateway then forwards the information to the 
payment processor 206, which then processes the information to either approve or deny the 
transaction. If the transaction is approved, then the information is forward to the back 208 to 
complete the transaction. 

[0033] The connectors in the form of software objects may communicate with the plurality 
of payment gateways through TCP/IP protocol or any other method known to one skilled in the 
art. The communication may be made through the Internet or may be directly linked via a 
dedicated hard line, wirelessly, or any other method known to one skilled in the art. 
[0034] With the above interfacing system 200, the merchant can switch to another payment 
gateway by selecting the desired payment gateway from the menu list provided by the API 202. 
The merchant may also process the transaction through a particular payment gateway based on a 
predetermined condition established by the merchant. For instance, the merchant may set up a 
condition within the application system 101 where: if the credit card transaction is less than or 
equal to $100, then the payment gateway 206 is used, and for all other transactions, the payment 
gateway 208 is used. Such dual transaction condition may allow the merchant to take advantage 
of the fee arrangement offered by the competing payment gateways, where one payment gateway 
offers a better fee arrangement for transactions less than or equal to $100, and another payment 
gateway offers a better fee arrangement for transactions above $100. 

[0035] Figure 3 illustrates that the application system 201 may be an accounting package 
301, which requires the API 202 to operate within the accounting package 30 i. The accounting 
package such as Microsoft Great Plains® may not be able to communicate directly with the 
plurality of payment gateways 204. To facilitate the communication, glue 302 may be provided 
to allow communication amongst the API 202, the plurality of payment gateways 204, and a 
connection server 304. The glue 302 may be a dynamic link library (DLL) with executable 
functions that can be used by the accounting package. The DLL may act as a wrapper to provide 
compatibility between the accounting package 301 and the plurality of payment gateways 204, 
and allow the API to communicate with the connection server 304 as well. 
[0036] The connection server 304 may be communicateably coupled to a connector memory 
306 that stores data formatting information for each of the plurality of connectors supported by 
the API 202. In addition, the connector memory 306 may distinguish between required fields 
and optional fields, if any. The connection memory 30 may provide, the data formatting 
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requirements in the form of Extensible Markup Language (XML), which allows programmers to 
create their own customized tags, enabling the definition, transmission, validation, and 
interpretation of data between applications. This way, if there are any changes or updates on the 
data formatting requirements for a payment gateway, the XML corresponding to the payment 
gateway may be changed rather than recoding and reconfiguring the fields that were hard coded 
into the software. 

[0037] The connection server 304 may also be communicateably coupled to a template 
memory 308. Each payment gateway may have a unique style in terms of look and feel of the 
template screen. For instance, the type of font and font size may be different for each of the 
payment gateways. The template memory 308 may have a particular template formatting 
requirement for each of the payment gateways. The template memory 308 may provide the 
template requirement in the form of Extensible Style Language (XSL), which is a specification 
for separating style from content when creating Hyper Text Markup Language (HTML) or XML 
pages. 

[0038] Once the API 202 is installed within the accounting package 301, a user may select at 
least one connector corresponding to a particular payment gateway from the menu list provided 
by the API 202. When a customer is ready to process a transaction using a credit card, based on 
the connector selected by the user, the accounting package 301 communicates to the API 202 the 
connector to use for the transaction. The API 202 communicates with the connector server 304 
the connector that is being used for the transaction. Based on the connector, the connector server 
304 retrieves from the connector memory 306 the data formatting requirements for the payment 
gateway corresponding to the connector. The connector memory 306 may provide the data 
formatting requirements to the connector server 304 in the form of XML. The connector server 
304 may also retrieve the template formatting requirements for the payment gateway 
corresponding to the connector. The template memory 308 may provide the template formatting 
requirements in the form of XSL. The connector server 304 forwards the data and template 
formatting requirements to the API 202. The API 202 forwards the data and template formatting 
requirements into HTML to the accounting package 301 to quarry the user for the required and 
optional fields with the right style as dedicated by the template formatting requirements. The 
quarry for the required fields may be distinguished from the optional fields so that the user may 
input data for the optional fields if desired. After the user inputs the required and optional fields, 
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the API 202 forwards the correctly formatted data to the payment gateway corresponding to the 
connector to process the transaction. 

[0039] Figure 4 illustrates an interfacing system 400 including the API 202 capable of 
processing credit card transactions for merchants using different application software or systems 
to process the transactions. Merchants may use a variety of application systems such as an 
external system 402, web-based system 404, .COM based system 406, or any other system 
known to one skilled in the art. The external system 402 may be any type of a software 
application that is running on a remote server that processes credit card transactions. The 
external system 402 running on the remote server may communicate with the API through a web 
server 408. The web server 202 may run on top of the API 202 to provide additional support for 
accessing the API 202 using simple object access protocol (SOAP)/XML. The web server 408 
may be used by both Windows® and non-windows based application software or systems that 
support SOAP. 

[0040] The API 202 may be also accessed by the web-based system 404 such a shopping cart 
system or a storefront that allows a customer to purchase a good or service through the web 
access. The web-based system 404 may communicate with the API 202 through the server-side 
scripting 410. In instances where the web-based system 404 is based on .NET, the web-based 
system 404 may communicate with the API 202 through the web server 408. The .COM based 
system 406 such as a point-of-sales system that operates within the same server as the API 202 
may communicate directly with the API 202. Accordingly, a variety of application software or 
systems such as point-of-sales, business-to-business portals, call centers, enterprise resource 
planning (ERP), or customer relationship management (CRM) systems may directly or indirectly 
communicate with the API 202 to process not only credit card transactions but other transactions 
as well. 

[0041] The API 202 may also communicate with a business adapter 412 that provides 
connection to external systems that may use the data in the transaction for accounting or for 
record keeping. For instance, the business adapter 412 may forward the data corresponding to 
the transaction to an accounting package 414 to record and keep track of the transaction. The 
business adapter 412 may also forward the data corresponding to the transaction to a memory 
bank 4 1 6 for storing the data for later use. 
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[0042] Once a connector is selected for processing the transaction, the application system is 
ready to process transactions. For instance, if the merchant hosting the web-based system 404 
has selected connector _1 corresponding to payment gateway_l to process the transaction, and a 
client is ready to purchase the items in the shopping cart by initiating a checkout button on the 
web page, the web-based system 404 communicates to the API 408 to process the checkout 
transaction using connector^ L The web-based system 404 may communicate with the API 202 
either through the web service 408, server-side scripting 410, or any other method known to one 
skilled in the art. The API 202 then retrieves the input field requirements for connectorj from 
connector memory 306. The input field requirements may include required fields and optional 
fields. The API 202 may then format the input field requirements into a HTML and forward the 
HTML to the web-based system 404 to display the web-page with required and optional input 
fields for the client to provide. 

[0043] Once the client is done inputting the required and the optional input fields, if any, the 
API 202 retrieves the inputted data and forwards the data to the payment gateway corresponding 
to connectorj, which in this. example is payment gateway_L The inputted data from the client 
is correctly formatted for payment gateway_l because the quarry to the user was based on the 
data formatting requirements of connector_l. The payment processor then either approves or 
denies the transaction. If the transaction is approved, then the data is sent to the bank to 
complete the transaction. The API 202 may also send the data to the business adapter to forward 
the data to the memory bank 416 and/or accounting package 414 to keep record of the 
transaction. 

[0044] In closing, it is noted that specific illustrative embodiments of the invention have 
been disclosed hereinabove. However, it is to be understood that the invention is not limited to 
these specific embodiments. For example, the invention is applicable for electronic check and 
ACH transactions. With respect to the claims, it is the applicant's intention that the claims not 
be interpreted in accordance with the sixth paragraph of 35 U.S;C. § 112 unless the term 
"means" is used followed by a functional statement. 
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What is claimed is: 

1 . A method for interfacing data between a first software and a second software to process a 
transaction between the first software and the second software, the method comprising: 

determining the data needed for processing a transaction from the second software by the 
first software; 

requesting the data from a client; and 
processing the transaction using the data. 

2. A method for making an electronic payment, comprising: 

determining the data needed from a payment processor to make an electronic payment; $ 
requesting the data from a client; 
retrieving the data from the client; and • 

processing the data through the payment processor to make the electronic payment. 

3. The method according to claim 2, where the data includes required information and 
optional information. 

4. The method according to claim 2, where the client is a web-based client. 

5. The method according to claim 2, where the data includes credit card information, 
electronic check, electronic cash, and electronic fund. 

6. A method for interfacing merchant's credit card processing system with a plurality of 
payment processors, the method comprising: 

determining the payment processor to be used from the plurality of payment processors 
for a credit card transaction; 

retrieving the data needed to process the credit card transaction through the payment 
processor; 

requesting the data from a client to process the credit card transaction through the 
payment processor; and 

processing the data through the payment processor to process the credit card transaction. 
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7. The method according to claim 6, where the data includes both required data and optional 
data. 

8. The method according to claim 7, further including reducing the credit card transaction 
fee if the merchant provides the optional data. 

9. The method according to claim 6, farther including, storing the credit card transaction 
into a memory. 

10. The method according to claim 6, further including, transmitting the information 
associated with the credit card transaction to an accounting package. 

11. The. method according to claim 6, where the merchant's credit card processing system is 
a web-based merchant, 

12. The method according to claim 6 5 where the merchant's credit card processing system is 
a point-of-sale merchant. 

13. The method according to claim 6 5 further including, providing a template with input 
fields to the merchant's credit card processing system for the requesting of the data. 

14.. The method according to claim 7, further including, providing a template with input 
fields for the required data and the optional data to the merchant's credit card processing system 
for requesting the data. 

16. A method for interfacing a merchant's payment processing system to a plurality of 
payment processors each having a plurality of input fields for completing a transaction, the 
method comprising: 

determining the payment processor corresponding to the transaction from the plurality of 
payment processors; 
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determining whether each of the input fields for the payment processor is a required input 
field or an optional input field to process the transaction; and 

requesting the required and optional input fields, if any, from a client through the 
merchant's payment processing system to process the transaction. 

17. A method for processing a payment transaction between a merchant's payment 
processing system and a plurality of payment processors each having a plurality of input fields to 
process a transaction, the method comprising: 

updating the plurality of input fields for each of the plurality of payment processors to 
process the transaction; and 

determining whether each of the input fields for the plurality of payment processors is a 
required input field or an optional input field to process the transaction. 

18. A system for interfacing a plurality of merchant's payment processing systems with a 
plurality of payment processors each having a plurality of input fields to process a plurality of 
payment transactions between the plurality of merchant's payment processing systems and the 
payment processors, the system comprising: 

a memory storing the plurality of input fields for a predetermined number of payment 
processors, where the plurality of input fields include required and optional input fields, if any; 
and 

a server capable of requesting from a merchant's payment processing system a payment 
processor to use to process a payment transaction and retrieving from the memory the required 
and optional input fields corresponding to the payment processor. 

19. A system for interfacing a first software with a second software to process a transaction 
between the first and second software, the system comprising: 

a memory storing first required and optional input parameters to process the transaction 
through the first software; and 

a server capable of communicating with the memory to determine the first required . and 
optional input parameters and acquiring from the second software the first required and optional 
input parameters, if any, to process the transaction from the second. software to the first software. 
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20. The system according to claim 19, where the memory stores second required and optional 
input parameters to process the transaction through the second software, the server acquires from 
the first software the second required and optional input parameters, if any, to process the 
transaction from the first software to the second software. 

21. A system for interfacing a first software with a second software to process a transaction 
between the first and second software, the system comprising: 

a memory storing first required and optional input parameters to process a first 
transaction at the first software and storing second required and optional input field parameters to 
process a second transaction at the second software; and 

a server capable of communicating with the memory to determine the first and second 
required and optional input parameters and acquiring the first required and optional input 
parameters from the second software and providing the first required and optional input 
parameters to the first software to process the first transaction, the server further capable of 
acquiring the second required and optional input parameters from the first software and 
providing the second required and optional input parameters to the second software to process 
the second transaction. 
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ABSTRACT 

This invention relates to a credit card processing system that integrates between a 
variety of application software and a variety of processing engines. This allows companies the 
freedom to choose the method of communicating, technology, and price point that meet then- 
needs based on the volume of credit card transactions. This may be accomplished by "wrapping" 
various processing engines with a unified standard to eliminate the need for the client to integrate 
certain processing engines that .do not support certain processors. 
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